QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/tcp/940036.txt

Internet Message Format | 1994-11-13 | 17KB

Date: Tue,  8 Feb 94 04:30:01 PST
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #36
To: tcp-group-digest


TCP-Group Digest            Tue,  8 Feb 94       Volume 94 : Issue   36

Today's Topics:
                               Apology
        Can I attach (KA9Q) Net to Local Talk using Phonenet?
          Does exist Ethernet Driver for Net/Mac? (2 msgs)
                         Mail Delivery Status
       param slottime & persist command - description? (2 msgs)
                                PMNOS
                     Some Questions About Basics
                     WWW  Ka9q Server?? (2 msgs)
                   X.400 Distribution Status Report

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Mon, 7 Feb 94 11:56:35 PST
From: [e-mail] (Ken Koster)
Subject: Apology
To: [e-mail]

  My apologies to the group for the rash of old postings from 'gateway'
recently.

  For approximately the last 3 years I've been redistributing this list
to the local tcp/ip community via a local mailing list.  Users have
been able to subscribe to the list and respond back via my uucp connection
'algedi.data-io.com'.  To the best of my knowledge we've never had a
problem.  Until now. :-(

  Due to a problem (as yet unknown) at one of the local stations at least
11 messages were resent to the list.

  I've temporarily disabled the ability for local users to respond until
we can fix the problem.

73's,  Ken  N7IPB    [e-mail]

------------------------------

Date: Mon, 7 Feb 94 17:24 CDT
From: [e-mail] (Eduardo Millar)
Subject: Can I attach (KA9Q) Net to Local Talk using Phonenet?
To: [e-mail]

I have a Local Talk Network with Mac/TCP. We have connect the Local Talk
Network with another TCP Network by radio-links. For radio-links we
have used KA9Q package in PC. On the other hand I have Farallon Phonenet PC
to connect a PC with Local Talk. My question is: Can I use the PC like
Net/Router and connect this PC to Localtalk with Phonenet PC and using
TCP/IP protocols?.

I hope you anderstand to me. My English is not so good.


--------------------------------------------------------------------------------
Eduardo Millar C.                 e-mail: [e-mail]
Area Telecomunicaciones
Proyecto Enlaces
Ufro-Mece
Temuco- Chile
--------------------------------------------------------------------------------

------------------------------

Date: Mon, 7 Feb 94 11:12 CDT
From: [e-mail] (Eduardo Millar)
Subject: Does exist Ethernet Driver for Net/Mac?
To: [e-mail]

I have been used Net/Mac in a Local Talk network. The installations where
I work, exist Ethernet
Macintosh Network and I have to links this netwok with another Ethernet
Macintosh Network by Radio. My question is: Anyone know a version of
NetO/Mac that support any ethernet driver?..

------------------------------

Date: Mon, 7 Feb 1994 10:31:23 -0900
From: [e-mail] (Dewayne Hendricks)
Subject: Does exist Ethernet Driver for Net/Mac?
To: [e-mail] (Eduardo Millar), [e-mail]

At 11:12 2/7/94 -0500, Eduardo Millar wrote:
>I have been used Net/Mac in a Local Talk network. The installations where
>I work, exist Ethernet
>Macintosh Network and I have to links this netwok with another Ethernet
>Macintosh Network by Radio. My question is: Anyone know a version of
>NetO/Mac that support any ethernet driver?..

        NET/Mac does not support direct Ethernet connections.  For
instance, it cannot talk to MacTCP when it is configured via its control
panel to use the Ethernet interface. NET/Mac does support EtherTalk, but
not Ethernet.

-- Dewayne


--------------------------------------------------------------------------
Dewayne Hendricks, WA8DZP ! CIS: 75210,10    AppleLink: D6547
Tetherless Access Ltd.    ! Packet Radio: WA8DZP @ K3MC.#NOCAL.CA.USA.NOAM
43730 Vista Del Mar       ! AOL: HENDRICKS
Fremont, CA 94539-3204    ! Internet: [e-mail]
Phone: [phone]     ! Fax: [phone]
--------------------------------------------------------------------------

------------------------------

Date: 07 Feb 1994 12:16:12 EST
From: "Central Postmaster" <[e-mail]>
Subject: Mail Delivery Status
 ***** Error in Mail Delivery *****

INVALID RECIPIENT

 Recipients:

 [e-mail]

------------------------------

Date: Mon, 7 Feb 1994 14:12:28 -0600
From: [e-mail] (Milton Miller)
Subject: param slottime & persist command - description?
To: [e-mail], [e-mail]

On Mon, 31 Jan 1994 03:24:45 +1030 (CST) in <[e-mail]>,
[e-mail] asked:

>
> Hello.
>
> I have been trying to find an accurate consise description of exactly
> what the function of the 'persist' and 'slottime' functions are that
> are set using the param command in NOS and how these parameters
> affect radio channel performance. My understanding is that they are
> a replacement for DWAIT which is found in many TNC software EPROMS.
>

P-Persist is a alternative channel access protocol that reduces the
"everybody waiting starts transmitting at once" problem found in
the DWAIT protocol.

First, a short explanation of DWAIT:   When a station has data to send,
it first checks if the channel is busy.  If so, then it waits until it
clears, then keys and sends its data.  The DWAIT protocol says it will
wait y 10s of milliseconds for a digipeater to start transmitting
before seizing the channel.  For digipeated frames, the DWAIT time is
bypassed, effectively giving priority to digipeated frames.  Some of
the problems incurred with this scheme are: (1) the digipeater has to
check the crc, decide to send the data, and sieze the channel within
the dwait window for it to gain any advantage (which isn't possible in
KISS mode, because it has to go across the serial port to the host
twice), and (2) As the channel becomes more crowded, the chances of
having two stations waiting to send a packet increases.  If their
timeouts are the same length, they will continue to key on top of each
other, resulting in a sequence of collisions.

P-Persist instead relies on probabilities and random numbers to keep
(2) from happening.   When a station has data to send (be it new or
digipeating information), it waits for the channel to clear.  At that
point, it picks a random number between 0 and 255.  If it is less than
or equal to the PERSISTance, it will sieze the channel and transmit.
If not, it will wait SLOTTIME and then pick a new number if the channel
is still free, repeating the process.  As long as the numbers don't
match, you won't continue to collide with the same station.

Some MFJ firmware releases combine the two protocols by waiting for
dwait before starting p-persist.

Advice on choosing parameters:  [I am sure someone will correct me if I have
these wrong :-)   I admit I haven't read the papers describing the
studies.]

The persistance plus 1 is divided by 256 to get the fraction of the
time you will sieze the channel during any given slot.  To avoid
congestive collapse, it should be less than 1/(number of stations with
data to transmit at any given time).  Be sure to allow for more
stations to come on your frequency, as it will run much better.  But,
as someone else pointed out, be facist about getting their parameters
set right!  (if they are too agressive, your station will kindly back
off and wait for them to finish :-).  For slot time, the time should be
at least TXdelay, because that is supposedly how long it takes for a
station to key up and have all the recievers recgonize the station
being on the air.  If all stations don't use the same slot time, then
the back off doesn't help as much because the decision slots will not
line up.  If they are skewed far enough, a slot will appear as no
activity even though another started in transmitting in the "previous"
slot.  Note this can still happen if the station decides it has data
during the middle of an idle slot.

[ brainstorm:  this last issue could be addressed by requiring stations
to wait for the channel to go busy and then idle before transmitting,
unless the channel stays idle for some time >> slottime.  Comments? ]


> Could somebody point me in the direction of a document or file that
> describes this function? Also which layer of the OSI protocol stack
> do these functions belong to? (I am guessing level 1?)

In addition to what I stated above, the Kantronics manual gives a
reasonable description (although I don't remember any more
information).  Somewhere there have been a few papers written.

>
> Also I am interested to find out if there is any implementation of the
> T2 timer described in the AX.25 v2.0 protcol specification in the
> NOS package for AX.25 connections or IP virtual circuits carried on
> AX.25? (This parameter is the equivalent of what in the popular TNCs
> is seemingly called RESPTIME).

Well, I guess that is the frame ack timers, but haven't looked at the
source.  I don't know the timers by their t number.

>
> Cheers de Grant VK5ZWI

Hope this helps.  I haven't seen any replies to the list, and I finally
got a few minutes to type this in.

milton
--
Milton Miller  KB5TKF  [e-mail]  [e-mail]
I never speak for IBM.

------------------------------

Date: Mon, 7 Feb 1994 17:05:11 -0800
From: Phil Karn <[e-mail]>
Subject: param slottime & persist command - description?
To: [e-mail]

>> Also I am interested to find out if there is any implementation of the
>> T2 timer described in the AX.25 v2.0 protcol specification in the
>> NOS package for AX.25 connections or IP virtual circuits carried on
>> AX.25? (This parameter is the equivalent of what in the popular TNCs
>> is seemingly called RESPTIME).

>Well, I guess that is the frame ack timers, but haven't looked at the
>source.  I don't know the timers by their t number.

These timers are optional in AX.25. If you run with MAXFRAME=1, then
they don't do much since there's no point in waiting in case another
frame gets sent before you ack the current one. Also, the round-robin
scheduling in NOS usually (but not always) causes automatic piggybacking
of the AX.25 ack on any data being sent in response to the AX.25 data.

Phil

------------------------------

Date: Tue, 8 Feb 1994 09:04:08 GMT+1
From: Peter van der Post <[e-mail]>
Subject: PMNOS
To: [e-mail]

Hi everybody,

For a period of three months I have the chance to get some experience
with *real* E-mail, hi. Yesterday I took a subscription on this group
and, wow, a reply from ucsd.edu in 30 seconds, I couldn't dream of
such a quick response using packet radio, hi.

Well to the point now. As an OS/2 user, I am a happy user of the
Presentation Manager programs PMNOS en PMail by Walt Corey, KZ1F. It
has been quite some time since I've heard or read from Walt. The
latest news from Walt was that he had released version 1.1 of PMNOS.
That was in the very beginning of 1993. Walt told us that he was
working on something completely new, I guess, a Workplace Shell
integrated version of the NOS en PMail functions/services. He
mentioned the names WPNOS en WPMail some time.

Together with a lot of other OS/2 users, I would very much like to
know if Walt is still working on it. He made some promises about an
SCC driver, which is at the top of my PMNOS wish list, hi.

Well, thanks in advance for any replies,

73, Peter PE1NNH.

------------------------------

Date: Mon, 7 Feb 1994 14:39:32 -0600
From: [e-mail] (Milton Miller)
Subject: Some Questions About Basics
To: [e-mail], [e-mail]

On Sun, 30 Jan 1994 22:03:24 -0500 (EST),
John Stewart <[e-mail]> asked:

Disclaimer: I don't use packet drivers, so I will answer best guess.

>     I am trying to understand what interrupt buffers are used
> for in NOS? Are they used on both transmit and receive?

Only on receive (transmit buffers are allocated with interrupts
enabled).

>     Given that ibufsize should be greater than or equal to MTU,
> does the TCP WINDOW setting have an effect on the number of buffers
> that you need?

Yes, but it is your advertised recieve window, not your (maximum) send
window.  You need as many ibuf's as you expect packets from all hosts
in your processing loop time.  This should be at least the number of
packets in a window (considering mss and mtu induced fragments).  If
you often have several connections activly sending data (ie multiple
inbound ftps), you may need more.   You can set it high for a while and
see what minfree is, then lower it if it is excessive.

>
>     Does the transmit queue length on the ATTACH PACKET statement
> have an effect on the number of buffers that you need?

I am not familiar with that parameter.

>     I have read the NOS documentation and some other references, but
> am still missing part of the story. Can someone enlighten me?
>
> Thanks.
>
> John, n4qi
> Internet: [e-mail]
> AmprNet:  [e-mail]

milton
--
Milton Miller  KB5TKF  [e-mail]   [e-mail]
I never speak for IBM.

------------------------------

Date: Mon, 7 Feb 1994 11:52:41 -0600
From: [e-mail] (Milton Miller)
Subject: WWW  Ka9q Server??
To: [e-mail]

I found a tidbit in alt.winsock and followed up to get the following
reference:

Current supports ....
searches (2 or 3 types)
CSO database
auto-index-file generation
ascii and binary transfers
IP based item access

Here is the address of my Gopher / HTTP server

gopher://biochemistry.bioc.cwru.edu/
or
http://biochemistry.bioc.cwru.edu/


Regards,
milton
--
Milton Miller  KB5TKF  [e-mail]  [e-mail]
I never speak for IBM.

------------------------------

Date: Mon, 07 Feb 1994 20:40:27 -0500
From: [e-mail] (Ashok Aiyar)
Subject: WWW  Ka9q Server??
To: [e-mail]

>
>I found a tidbit in alt.winsock and followed up to get the following
>reference:
>
>Current supports ....
>searches (2 or 3 types)
>CSO database
>auto-index-file generation
>ascii and binary transfers
>IP based item access
>
>Here is the address of my Gopher / HTTP server
>
>gopher://biochemistry.bioc.cwru.edu/
>or
>http://biochemistry.bioc.cwru.edu/
>

I had not intended to advertise it, but there is an excellent
Gopher server for KA9Q.  This is written by Chris McNeil of
Mt. Allison Univ., Canada.  In the post on alt.winsock, when I
referred to my Gopher, I referred to the computer that I am
running Chris' Gopher server on.

Based on Chris' code, I do have a very crude HTTPD working on
the same machine.  That is the second thing referred to above.

Later,
Ashok
--
Ashok Aiyar                        Mail: [e-mail]
Department of Biochemistry                       Tel: [phone]
CWRU School of Medicine, Cleveland, Ohio         Fax: [phone]
MIME Enclosures OK

------------------------------

Date: 07 Feb 1994 14:56:14 EST
From: "X.400 Postmaster" <[e-mail]>
Subject: X.400 Distribution Status Report
To: [e-mail]

                         Soft-Switch X.400 Gateway
                         Distribution Status Report
2/07/94                                                               14:56:44
===============================================================================

Status:   Unable to deliver mail as timeout occured while routing
Subject:  TCP-Group Digest
           Surname:        GPARKE04
           Country:        US
           Admin. Domain:  TELEMAIL
           Private Domain: HARRIS
           Organization:   COMM
           Org Unit 1:     HDD
           Org Unit 2:     ENGRPOST

------------------------------

End of TCP-Group Digest V94 #36
******************************